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BACKGROUND 



Field of the Invention 
20 [001] The present invention relates to techniques for heightening security 

in communication protocols. More specifically, the present invention relates to a 
method and an apparatus for increasing network security by encapsulating 
cryptographic information across different network layers. 



25 Related Art 

[002] The explosive growth of the Internet has led to a proliferation of 
networked devices over the past few years. Due to a large increase in the number 
of networked devices, the Internet Protocol version 4 (IPv4) address space, which 
is based on a 32-bit long address format, will soon run out of usable addresses. 

30 To solve this problem, Internet Protocol version 6 (IPv6) was proposed. IPv6 

defines a 128-bit long address format, which is believed to provide a sufficient 
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number of addresses to accommodate all networked devices. These networked 
devices can include cell phones, personal data assistants (PDAs), and other 
computing devices. 

[003] Unfortunately, when IPv6 was designed many years ago, it was 
5 difficult to foresee the wide deployment of wireless networks that are being used 
today. Hence, the IPv6 mechanisms that manage local links were designed with 
physically protected, trustworthy links in mind. Today, people are planning to use 
IPv6 on public wireless networks, such as Wireless LANs (WLANs) in airports, 
hotels, etc. In such networks, even though an actual link may be somewhat 

10 protected with layer two (data link layer) authentication, access control, and 
encryption, some of the nodes on the link could still be untrustworthy. 
Furthermore, it is easy to set up a non-authentic WLAN base station that can be 
used to launch various types of attacks, such as access stealing, Denial-of-Service 
(DoS) attacks, and traffic-snooping attacks. 

1 5 [004] To address these security problems in IPv6, a Cryptographically 

Generated Address (CGA) can be used. In essence, a CGA allows a node to use a 
short but secure expression of its public key (for example, a part of a secure hash 
of the public key) as part of its IPv6 address. This CGA mechanism actually 
allows a node to prove that it has the authorization to use a particular address. 

20 This simple but powerful concept has far-ranging implications and applications to 
network security, reaching beyond IPv6 networks. 

[005] A similar concept is that of a "Hash Based Address" (HB A). It 
also uses a secure hash (e.g., SHA-1); but instead of a public key, the input to the 
secure hash function is a static identifier. Accordingly, an HBA alone cannot 

25 prove that its owner is the sole entity authorized to perform certain operations on 
the address. Nevertheless, they do have the non-reversible property of the secure 
hash function. Hence, they can be used to prove that an HBA is a special type of 
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address, one that is derived securely from certain (perhaps public) parameters. 
This property of safely distinguishing addresses, between those that have the HBA 
property and those that do not, is quite useful to prevent certain types of attacks. 
[006] Both the CGA and HBA proposals define ways to derive IPv6 
5 addresses. However, both of the above suffer from the limitation that an IPv6 
address (more specifically, the interface-identifier part of an IPv6 address) leaves 
only 62 bits available for the hash value. In order to derive the security properties 
of CGA/HB A schemes, enough bits are required so that the uniqueness properties 
of the secure hash are maintained. The secure hash function SHA-1 produces 160 
1 0 bits, but with the limitation of IPv6 addresses (and other CGA/HB A applications), 
the output must be truncated and not all 160 bits can be used. 

[007] Nevertheless, it is generally acknowledged that 128 bits and even 
fewer bits (approximately 100 bits) are more than enough for protection against 
attackers trying to find collisions on the secure hash by brutal force. 
1 5 [008] However, in the case of CGA/HB A, people increasingly question 

whether 62 bits are enough. 

[009] There have been some efforts to work within the 62-bit limitation 
by trading off increased protection with increased work load when generating the 
addresses. This is not nearly as practical as being able to keep more bits from the 
20 output of the secure hash function. 

[0010] Hence, what is needed is a method and an apparatus that allows 
more bits to be used with the CGA and HBA techniques. 

SUMMARY 

25 [0011] One embodiment of the present invention provides a system that 

communicates cryptographic data through multiple network layers. During 
operation, the system receives the cryptographic data and divides the 
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cryptographic data into multiple pieces. The system then encapsulates different 
pieces of the cryptographic data into fields associated with different network 
layers in a data packet, whereby an item of cryptographic data that is too large to 
be communicated in a single field can be communicated through multiple fields 
5 associated with different network layers. 

[0012] In a variation of this embodiment, receiving the cryptographic data 
involves performing a non-reversible function on input data to produce the 
cryptographic data. 

[0013] In a further variation, the input data includes a public key 
1 0 associated with the node. 

[0014] In a further variation, the input data includes a static identifier 
associated with the node. 

[0015] In a further variation, an IPv6 address field of the data packet is 
comprised of a 64-bit prefix followed by the most-significant 64 bits of the output 
1 5 of the non-reversible function, wherein a universal/local bit and an 
individual/group bit of the IPv6 address are both set to "0". 

[0016] In a further variation, an SSH public-key fingerprint field of the 
data packet is comprised of the least-significant 128 bits of the output of the non- 
reversible function. 

20 [0017] In a further variation, a MAC address field of the data packet is 

comprised of the least-significant 64 bits of the output of the non-reversible 
function. 

[0018] In a further variation, a JXTA Peer-ID field of the data packet is 
comprised of the least-significant 128 bits of the output of the non-reversible 
25 function. 



4 
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[0019] In a further variation, a JXTA Group-ID field of the data packet is 
comprised of the least-significant 128 bits of the output of the non-reversible 
function. 

[0020] In a further variation, a SIP Call-ID field of the data packet is 
comprised of a local-id and a host address, wherein the local-id is comprised of 
the least-significant 128 bits of the output of the non-reversible function; and 
wherein the host address is comprised of the IPv6 address. 

[0021] One embodiment of the present invention provides a system that 
verifies a data packet containing cryptographic data. Upon receiving the data 
packet, the system extracts pieces of cryptographic data from fields associated 
with different network layers within the data packet. The system then verifies that 
each piece of extracted cryptographic data matches with a corresponding portion 
of a piece of previously obtained cryptographic data. 

BRIEF DESCRIPTION OF THE FIGURES 

[0022] FIG. 1 illustrates the Open System Interconnect (OSI) network- 
layer reference model defined by the International Standards Organization (ISO). 

[0023] FIG. 2 illustrates how a crypto-based identifier (CBID) can be 
derived from performing a hash function on a public-key certificate in accordance 
with an embodiment of the present invention. 

[0024] FIG. 3 illustrates how cryptographic layering enforcement (CLE) 
can be implemented by using a cryptographic IPv6 address and a Secure Shell 
(SSH) public-key fingerprint that are both derived from a CBID in accordance 
with an embodiment of the present invention. 

[0025] FIG. 4 illustrates how CLE can be implemented by using a 
cryptographic IPv6 address and a cryptographic MAC address that are both 
derived from a CBID in accordance with an embodiment of the present invention. 
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[0026] FIG. 5 illustrates how CLE can be implemented by using a 
cryptographic IPv6 address and a cryptographic Session Initiation Protocol (SIP) 
Call-ID that are both derived from a CBID in accordance with an embodiment of 
the present invention. 
5 [0027] FIG. 6 illustrates how CLE can be implemented by using a 

cryptographic IPv6 address and a cryptographic JXTA group ID that are both 
derived from a CBID in accordance with an embodiment of the present invention. 

[0028] FIG. 7 illustrates how CLE can be implemented by using a 
cryptographic IPv6 address and a cryptographic JXTA peer ID that are both 
10 derived from a CBID in accordance with an embodiment of the present invention. 

[0029] FIG. 8 presents a flow chart illustrating how to construct a 
cryptographic IPv6 address and a SIP Call-ID from a CBID in accordance with an 
embodiment of the present invention. 

[0030] FIG. 9 presents a flow chart illustrating how to verify a packet 
15 containing a cryptographic IPv6 address and a SIP Call-ID against a CBID in 
accordance with an embodiment of the present invention. 

DETAILED DESCRIPTION 
[0031] The following description is presented to enable any person skilled 

20 in the art to make and use the invention, and is provided in the context of a 

particular application and its requirements. Various modifications to the disclosed 
embodiments will be readily apparent to those skilled in the art, and the general 
principles defined herein may be applied to other embodiments and applications 
without departing from the spirit and scope of the present invention. Thus, the 

25 present invention is not intended to be limited to the embodiments shown, but is 
to be accorded the widest scope consistent with the principles and features 
disclosed herein. 
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ISO/OSI Network Layer Model 

[0032] FIG. 1 illustrates the Open System Interconnect (OSI) network- 
layer reference model defined by the International Standards Organization (OSI). 
In an end-to-end data-delivery path, there are a source node 1 10, a destination 
5 node 140, and typically a number of intermediate routing nodes (routers 120 and 
130 in this example). Theoretically, the communication protocol stack of a node 
is comprised of seven layers: a physical layer (101), a data-link layer (102), a 
network layer (103), a transport layer (104), a session layer (105), a presentation 
layer (106), and an application layer (107). A data packet transmitted across a 
10 network typically includes fields corresponding to at least one of the OSI layers 
that carry certain address or identification information. 

Crypto-based Identifier 

[0033] FIG. 2 illustrates how a crypto-based identifier (CBID) can be 
1 5 derived from performing a hash function on a public-key certificate in accordance 

with an embodiment of the present invention. A public-key certificate 201 is fed 

into a secure hash algorithm (SHA-1) 202. The result of the hash function is then 

used as a CBID 203, which is 160 bits long. 

[0034] One embodiment of the present invention distributes CBID 203 
20 across multiple fields in multiple layers of the protocol stack. Another 

embodiment uses two fields in two layers, but there is nothing preventing one 

from encapsulating CBID bits in more than two layers. 

[0035] Each address or identifier in a particular layer that one wishes to 

use to encapsulate a portion of the CBID can be initialized as follows: the address 
25 or identifier contains a truncated sequence of bits of CBID 203, wherein the actual 

number of included CBID bits is determined by how many bits are available in the 

corresponding address or identifier of a specific layer (e.g., Media Access (MAC) 
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address, IP address, etc). Thus, portions of a single CBID can be embedded in 
fields associated with different layers of the OSI reference model. 

[0036] The hash of public-key certificate 201 can be obtained through a 
SHA-1 hash function with an output of 160 bits: CBID = SHA-l(PK), wherein 
5 PK represents the public-key certificate. If more than 160 bits are desired to be 
encapsulated in several fields associated with different layers, these bits can be 
obtained by performing the hash function multiple times to produce multiple sets 
of 160 bits; whereby the input to the first hash function is the public-key 
certificate, the input to the second hash function is the public-key certificate 

10 concatenated by one "1" bit, the input to the third hash function is the public-key 
certificate concatenated by two "1" bits, and so on. 

[0037] The above mechanism constitutes a "CLE" (Cryptographic 
Layering Enforcement) because a holder of a public key is required to use a 
number of verifiable identifiers and/or addresses corresponding to different OSI 

15 layers. The CBID binds together several vertically stacked (but not necessarily 
adjacent) layers. Because of the verifiability property of CBID's, and because a 
CBID is encapsulated across multiple layers, one is able to verify identifiers in 
multiple layers by checking the portions of CBID in these layers against the hash 
result of the sending node's public key. Moreover, this verifiability can be used to 

20 bootstrap a security association between two nodes, thus protecting a node from 
man-in-the-middle attacks on a Diffie-Hellman exchange. 

[0038] Possible applications of CLE are tailored to a given subset of the 
different OSI layers. Such examples include: IPv6 address (network layer) and 
Secure Shell (SSH) public-key fingerprint (application layer), IPv6 address and 

25 MAC address (data link layer), IPv6 address and Session Initiation Protocol (SIP) 
Call-ID (application layer), and IPv6 address and JXTA Peer-ID or Group-ID 
(application layer). 
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CLE Examples 

[0039] FIG. 3 illustrates how CLE can be implemented by using a 
cryptographic IPv6 address and an SSH public-key fingerprint that are both 
5 derived from a CBID. In FIG. 3 5 cryptographic IPv6 address 301 is comprised of 
a 64-bit network identifier, followed by the most-significant 64 bits of CBID 203. 
Note that both the universal/local bit ("u" bit) and the individual/group bit ("g" 
bit) in the IPv6 address are set to "0" to indicate that this is a cryptographically 
generated address. This effectively leaves 62 available bits in the IPv6 address to 
10 encapsulate a portion of CBID 23. 

[0040] The other part of CLE, an SSH public-key fingerprint 302, is 
comprised of the least-significant 128 bits of CBID 203. 

[0041] FIG. 4 illustrates how CLE can be implemented by using a 
cryptographic IPv6 address and a cryptographic MAC address that are both 
15 derived from a CBID, wherein a MAC address 403 is comprised of the least 
significant 64 bits of CBID 203 . 

[0042] FIG. 5 illustrates how CLE can be implemented by using a 
cryptographic IPv6 address and a cryptographic SIP Call-ID that are both derived 
from a CBID. A SIP Call-ID 503 includes a local-ID, which is comprised of the 
20 least significant 64 bits of CBID 203, and a host address, which is the same as 
IPv6 address 301. 

[0043] FIG. 6 illustrates how CLE can be implemented by using a 
cryptographic IPv6 address and a cryptographic JXTA group ID that are both 
derived from a CBID, wherein a JXTA group ID 603 is comprised of the least 
25 significant 1 28 bits of CBID 203 . 

[0044] FIG. 7 illustrates how CLE can be implemented by using a 
cryptographic IPv6 address and a cryptographic JXTA peer ID that are both 
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derived from a CBID, wherein a JXTA peer ID 703 is comprised of the least 
significant 128 bits of CBID 203. 

[0045] FIG. 8 presents a flow chart illustrating how to construct a 
cryptographic IPv6 address and a SIP Call-ID from a CBID. The system starts by 
performing a SHA-1 hash function on the node's public-key certificate in step 801 
to obtain a 160-bit CBID. Next, the system replaces the least-significant 64 bits 
of the node's IPv6 address with the most-significant 64 bits of the CBID (with the 
"u" bit and "g" bit set to u 0") to create a cryptographic IPv6 address (step 802). 
The system then use the least-significant 128 bits of the CBID as the SIP local-ID 
(step 803) and use the cryptographic IPv6 created in step 801 as the SIP host 
address (step 804). 

[0046] FIG. 9 presents a flow chart illustrating how to verify a packet 
containing a cryptographic IPv6 address and a SIP Call-ID against a CBID. The 
system starts by performing a SHA-1 hash function on a public-key certificate to 
obtain a 160-bit CBID 5 wherein the public-key certificate has been previously 
obtained from the sender (step 901). Next 5 the system verifies that the least- 
significant 64 bits of the IPv6 address of the received packet matches the most- 
significant 64 bits of the CBID (step 902). The system also confirms that the SIP 
local-ID matches the least-significant 128 bits of the CBID (step 903). 

[0047] The foregoing descriptions of embodiments of the present 
invention have been presented for purposes of illustration and description only. 
They are not intended to be exhaustive or to limit the present invention to the 
forms disclosed. Accordingly, many modifications and variations will be apparent 
to practitioners skilled in the art. Additionally, the above disclosure is not 
intended to limit the present invention. The scope of the present invention is 
defined by the appended claims. 
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